From 83bb5eb4d340acebf27b34108fb1dae062146a68 Mon Sep 17 00:00:00 2001 From: Jan Beulich Date: Tue, 29 Apr 2014 15:11:31 +0200 Subject: [PATCH] x86/HVM: restrict HVMOP_set_mem_type Permitting arbitrary type changes here has the potential of creating present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid MFN (INVALID_MFN truncated to the respective hardware structure field's width). This would become a problem the latest when something real sat at the end of the physical address space; I'm suspecting though that other things might break with such bogus entries. Along with that drop a bogus (and otherwise becoming stale) log message. Afaict the similar operation in p2m_set_mem_access() is safe. This is XSA-92. Signed-off-by: Jan Beulich Reviewed-by: Tim Deegan --- xen/arch/x86/hvm/hvm.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 4e14a21e3f..ac05160129 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4548,12 +4548,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) rc = -EINVAL; goto param_fail4; } - if ( p2m_is_grant(t) ) + if ( !p2m_is_ram(t) && + (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) ) { put_gfn(d, pfn); - gdprintk(XENLOG_WARNING, - "type for pfn %#lx changed to grant while " - "we were working?\n", pfn); goto param_fail4; } else -- 2.30.2